home *** CD-ROM | disk | FTP | other *** search
/ Aminet 31 / Aminet 31 (1999)(Schatztruhe)[!][Jun 1999].iso / Aminet / dev / c / vbccm68k.lha / vbcc / doc / vbccm68k.doc < prev    next >
Text File  |  1999-03-07  |  14KB  |  315 lines
  1. vbcc - C compiler (c) in 1995-99 by Volker Barthelmann
  2.  
  3.  
  4. INTRODUCTION
  5.  
  6.     vbcc is a free portable and retargetable ANSI C compiler.
  7.     It is clearly split into a target independant and a target dependant
  8.     part and supports emulating datatypes of the target machine on any
  9.     other machine so that it is possible to e.g. make a crosscompiler for
  10.     a 64bit machine on a 32bit machine.
  11.     This document only deals with the target dependant parts of the
  12.     Amiga68k version.
  13.  
  14.  
  15. LEGAL
  16.  
  17.     vbcc is (c) in 1995-99 by Volker Barthelmann. All code is written by me
  18.     and may be freely redistributed as long as no modifications are made
  19.     and nothing is charged for it.
  20.     Non-commercial usage of vbcc is allowed without any restrictions.
  21.     Commercial usage needs my written consent.
  22.  
  23.     Sending me money, gifts, postcards etc. would of course be very nice
  24.     and may encourage further development of vbcc, but is not legally or
  25.     morally necessary to use vbcc.
  26.  
  27.  
  28. ADDITIONAL OPTIONS FOR THIS VERSION
  29.  
  30.     -cpu=n      Generate code for cpu n (e.g. -cpu=68020), default: 68000
  31.  
  32.     -fpu=n      Generate code for fpu n (e.g. -fpu=68881), default: 0
  33.  
  34.     -sd         Use small data model (see below).
  35.  
  36.     -sc         Use small code model (see below).
  37.  
  38.     -prof       Insert code for profiling (not really usable yet).
  39.  
  40.     -g          Generate debugging hunks which contain addresses of static
  41.                 objects and links assembly instructions to source lines.
  42.                 This does not work with -gas.
  43.  
  44.     -const-in-data
  45.  
  46.                 By default constant data will be placed in the code
  47.                 section (and therefore is accessable with faster pc-relative
  48.                 addressing modes). Using this option it will be placed in the
  49.                 data section.
  50.                 This could e.g. be useful if you want to use small data and
  51.                 small code, but your code gets too big with all the constant
  52.                 data.
  53.                 Note that on operating systems with memory protection this
  54.                 option will disable write-protection of constant data.
  55.  
  56.     -use-framepointer
  57.  
  58.                 By default automatic variables are addressed through a7
  59.                 instead of a5. This generates slightly better code, because
  60.                 the function entry and exit overhead is reduced and a5 can be
  61.                 used as register variable etc.
  62.                 However this may be a bit confusing when debugging and you
  63.                 can force vbcc to use a5 as a fixed framepointer.
  64.  
  65.     -no-addressing-modes
  66.  
  67.                 The intermediate code does not contain any of the 68k
  68.                 addressing modes, so if they are to be used an extra pass
  69.                 over the intermediate code is necessary to recognize certain
  70.                 patterns that can be expressed using a 68k addressing mode.
  71.                 By default vbcc tries to use some 68k addressing modes.
  72.                 Currently (ax)+ and subsets of (displ,ax,dy*skal) are used.
  73.                 However not all cases where those addressing modes could be
  74.                 used are recognized.
  75.                 With this option you can prevent vbcc from searching for
  76.                 possible addressing modes. This may simplify debugging.
  77.  
  78.     -no-delayed-popping
  79.  
  80.                 By default arguments of function calls are not always popped
  81.                 from the stack immediately after the call, so that the
  82.                 arguments of several calls may be popped at once.
  83.                 With this option vbcc can be forced to pop them after every
  84.                 function call.
  85.                 This may simplify debugging and very slightly reduce the
  86.                 stack size needed by the compiled program.
  87.  
  88.     -gas        Create output suitable for the GNU assembler. This is
  89.                 mainly useful to create code for other operating systems.
  90.  
  91.     -no-fp-return
  92.  
  93.                 Do not return floats and doubles in floating-point registers
  94.                 even if code for an fpu is generated. This is mainly useful
  95.                 to create code for other operating systems.
  96.  
  97.     -no-mreg-return
  98.  
  99.                 Do not use multiple registers to return types that do not
  100.                 fit into a single register. This is mainly for backwards
  101.                 compatibility.
  102.  
  103.     -d2scratch  obsolete
  104.  
  105.     -noa4       obsolete
  106.  
  107.  
  108. SOME INTERNALS
  109.  
  110.     The current version generates assembler output for use with the PhxAss
  111.     assembler (c) by Frank Wille. Most peephole optimizations are done by the
  112.     assembler so vbcc only does some that the assembler cannot make.
  113.     The generated executables will probably only work with OS2.0 or higher.
  114.  
  115.     With -gas assembler output suitable for the GNU assembler is generated
  116.     (the version must understand the Motorola syntax - some old ones do not).
  117.     The output is only slightly modified from the PhxAss-output and will
  118.     therefore result in worse code on gas. However this code generator should
  119.     be usable on most operating systems on 68k machines that way.
  120.  
  121.     The register names are:
  122.  
  123.          a0,  a1,  a2,  a3,  a4,  a5,  a6,  a7
  124.          d0,  d1,  d2,  d3,  d4,  d5,  d6,  d7
  125.         fp0, fp1, fp2, fp3, fp4, fp5, fp6, fp7
  126.  
  127.     The registers d0, d1, a0, a1, fp0 and fp1  are used as scratch registers
  128.     (i.e. they can be destroyed in function calls), all other registers are
  129.     preserved.
  130.  
  131.     All elementary types up to 4 bytes are returned in register d0 like
  132.     common on the Amiga (although I think pointers should better be returned
  133.     in a0). If compiled for an fpu, floating point values are returned in
  134.     fp0 unless -no-fpreturn is specified.
  135.     Types which are 8, 12 or 16 bytes large will be returned in several
  136.     registers (d0/d1/a0/a1) unless -no-mreg-return is specified.
  137.     All other types are returned by passing the function the address
  138.     of the result as a hidden argument - so when you call such a function
  139.     without a proper declaration in scope you can expect a crash.
  140.  
  141.     You must not link objects together that have been compiled with
  142.     different settings!
  143.  
  144.     vbcc uses d0-d7 and a0-a6 for temporary results and register variables
  145.     (a4 is used as small data pointer if -sd is used). a5 can be
  146.     used as frame pointer for automatic variables (but this is not necessary -
  147.     they can be accessed through a7, too). At the moment all local
  148.     variables are addressed via (dist,ax), so a function may have only ~32k
  149.     of local variables if code for <=68000 is generated.
  150.  
  151.     The elementary data types are represented like:
  152.  
  153.     type        size in bits        alignment in bytes
  154.  
  155.     char                8                       1
  156.     short              16                       2
  157.     int                32                       2
  158.     long               32                       2
  159.     all pointers       32                       2
  160.     float(fpu)         32                       2       see below
  161.     double(fpu)        64                       2       see below
  162.  
  163.     Although it would be better to have all 32bit+ types aligned to 4 bytes
  164.     I chose 2 bytes to be compatible with the Amiga system structures which
  165.     unfortunately have longwords aligned to 4n+2-addresses.
  166.  
  167.     The amiga68k code generator at the moment only works on systems
  168.     that store floats and doubles in a similar way (IEEE) like the Amiga.
  169.  
  170.  
  171. SMALL DATA
  172.  
  173.     vbcc can access static data in two ways. By default all such data will
  174.     be accessed with full 32bit addresses (large data model).
  175.     However there is a second way. You can set up an address register (a4)
  176.     to point into your data segment and then address data with a 16bit
  177.     offset through this register.
  178.     The advantages of the small data model are that your program will
  179.     usually be smaller (because the 16bit offsets use less space and no
  180.     relocation information is needed) and faster.
  181.     The disadvantages are that one address register cannot be used by the
  182.     compiler and that you can use it only if all your static data occupies
  183.     less than 64kb. Also you may not mix object modules and libraries that
  184.     have been compiled with different data models (